Backup Architecture

Summary

A backup architecture defines what is protected, where copies live, and how recovery is validated. In self-hosted environments, the architecture must account for application data, infrastructure configuration, and the operational steps needed to restore service safely.

Why it matters

Many backup failures are architectural rather than tool-specific. Storing copies on the wrong system, skipping configuration, or never testing restores can make an otherwise successful backup job useless during an incident.

Core concepts

• Multiple copies across different failure domains
• Separation of live storage, backup storage, and off-site retention
• Consistent backups for databases and stateful services
• Restore validation as part of the architecture

Practical usage

A practical backup architecture usually includes:

• Host or VM backups for infrastructure nodes
• File or repository backups for application data
• Separate backup of configuration, Compose files, and DNS or proxy settings
• Off-site encrypted copy of critical repositories

Example model:

Primary workloads -> Local backup repository -> Off-site encrypted copy
Infrastructure config -> Git + encrypted secret store -> off-site mirror

Best practices

• Back up both data and the metadata needed to use it
• Keep at least one copy outside the main site or storage domain
• Use backup tooling that supports verification and restore inspection
• Make restore order and dependency assumptions explicit

Pitfalls

• Treating snapshots as the only backup mechanism
• Backing up encrypted data without preserving key recovery paths
• Assuming application consistency without database-aware handling
• Skipping restore drills for high-value services

References

• restic documentation
• BorgBackup documentation
• Proxmox VE Backup and Restore